Lift the Chronicle pin to 16.30.1 - #68
Conversation
Chronicle 16.30.1 restores skipping TLS certificate validation by default, so the CLI connects to a development server out of the box again and the pin at 16.19.3 has nothing left to hold back.
|
Reviewer context. #67 was fixed upstream today, not here. Chronicle/Chronicle#3707 merged 2026-08-13 18:15 UTC and shipped in v16.30.1, restoring the client default this issue was filed against. Verified in the released code rather than from the release note — Tested the workflow the issue is actually about, since the integration suite would not have proven it: Only the client version moves between those two lines. The documentation needs no change after all. #67 recorded two doc statements as wrong; both describe the pre-16.20.0 behavior, which is the behavior 16.30.1 restores. Verification: 436 unit specs, 161/161 integration specs — the same suite that had 108 failures on 16.20.0. Debug and Release both clean. Not verified: nothing was tested against a Chronicle server older than 16.30.1, so this says nothing about a CLI on 16.30.1 talking to an out-of-date deployment. |
The integration fixture names its container image after the Chronicle package version, so every version bump faces a cold ~400MB pull. Testcontainers times the first start attempt out while that pull runs, and each retry then collides with the port the timed-out attempt still holds - which surfaces as 'Bind for 0.0.0.0:27018 failed: port is already allocated' and reads like a code failure. Pulling first takes the download off the start clock.
The health wait allowed fifteen seconds. Chronicle serves HTTPS about twelve seconds after start on a warm image and a fast machine, so a two-core runner had no margin - and running out of it does not report a timeout. Testcontainers retries the start ten times and the container from the timed-out attempt is still holding the published ports, so every retry fails with 'port is already allocated' and the real cause never appears in the log.
|
Two commits were added after the version bump, both about getting CI to run at all. Neither is user-facing, so neither is in the description. The bump broke CI, and the error pointed three layers away from the cause. Every run failed with: That is a cascade. The health wait allowed 15 seconds; I timed the container and it serves HTTPS about 12 seconds after start on a warm image and a fast machine, so a two-core runner has no margin. Running out of it does not report a timeout — Testcontainers retries the start ten times, and the container from the attempt that timed out is still holding the published ports, so every retry reports the port instead. Raised to two minutes, which costs nothing when the container is quick: the strategy returns as soon as it answers. This bites on any Chronicle version bump, not just this one — the image tag is derived from the package version ( The pre-pull step is kept because it is right regardless: a ~400MB download inside the start window is not something to leave to chance. The evidence it works is the failure arriving 28 seconds sooner once it was in place. Four hypotheses I tried and discarded first, in case they save someone else the time: not my change (main's last run passed the same job, mine failed 3/3); a flake (re-ran identically); the cold pull (pre-pulled — same failure); parallel fixtures racing for the port (one collection, one fixture, 53 files share it). What broke it open was diffing the fixture between 16.19.3 and 16.30.1 — byte-identical, so only the image had changed, which pointed at startup time. Final state: 436 unit specs, 161/161 integration. One run had 3 failures in |
1 participant
Changed